Business processes present business logic of enterprises and/or web services. Business processes are the business practices and procedures that all organizations implement to run their business. Many business processes are encapsulated into specific business applications. However, a business process is typically end-to-end and does not normally start and stop within one business application. For example, the process of ordering goods does not stop once the goods have been entered into an order processing system. An example of an end-to-end business process may include activities such as picking the goods in the warehouse, dispatching the goods to a courier, and recording that the goods have been delivered and that the customer is satisfied. In the dynamic Internet-based business environment, organizations may need to frequently redesign their business processes. However, such redesign is a very costly procedure and may result in an inefficient redesign.
Business Processes Management Systems (BPMS) are software applications that support the definition, execution, and management of business processes. BPMSs are being increasingly used both in traditional and in Internet-based enterprises to support administrative and production processes, execute e-commerce transactions, and monitor business operations. In fact, BPMSs typically allow companies to reduce costs and to improve the speed and quality of business process 100 executions. One of the main features of BPMS tools is the availability of a business process modeling facility, which enables business process designers to describe the many aspects involved in a business process execution, such as tasks, execution flows, data flows, resources, constraints, and exceptions. In addition, BPMSs also provide support for business process modification and versioning.
A business process model of a Business Process Management System outlines business process definition elements and their relationships. FIG. 1 illustrates a model for an exemplary business process 100. The business process 100 is described by a directed graph that may have several different kinds of nodes. Work nodes 105 represent the invocation of activities (also called services) that may be assigned for execution to a human or automated resource. Route nodes 110 are decision points that route the execution flow among nodes based on an associated routing rule. Event nodes (not shown) may denote points in the business process 100 where an event is notified to or requested from other business processes 100. A start node 115 denotes the entry point to the business process 100. A complete node 120 denotes the termination point. Arcs 107 in the graph denote execution dependencies among nodes. When a work node 105 execution is completed, the output arc 107 is fired, and the node connected to that arc 107 is activated. Arcs 107 in output of route nodes 110 are fired based on the evaluation of the routing rules. Other models for business processes 100 than the one shown in FIG. 1 are possible.
FIG. 1 depicts an exemplary procurement business process 100. When a purchase request is issued through a web based front-end interface, an instance of this procurement business process 100 is created to handle this request. Every work node 105 is associated with a service (also called an activity) description, that defines the logic for selecting a resource (or resource group) to be invoked for executing the work. The service may also define the business process data items to be passed to the resource upon invocation and received from the resource upon completion of the work. Several work nodes 105 can be associated with the same service description.
While designing business processes 100 with such tools is feasible, designing good business processes 100 is extremely difficult for several reasons. First, business processes 100 are designed by a business process modeler who interviews individuals (e.g., business and information technology people) in an organization in order to discover and understand their actual or desired business processes 100. This is a difficult endeavor, and problems arise due to lack of complete information, lack of communication, lack of understanding, etc.
Secondly, designing good business processes 100 is difficult because business processes 100 have many different facets that need to be perfectly orchestrated in order to obtain optimal results. Third, it is difficult to predict the actual workload of the business process 100, and therefore it is difficult to define business process aspects (such as assignment to resources) that are affected by workload considerations. Fourth, although different business processes 100 are often designed independently and may be conceptually unrelated, they do interact in several ways. For example, they may share resources (e.g., human or automated), invoke the same services, and/or run on top of the same BPMS (thereby sharing the system resources). For these reasons, executions of a business process 100 may impact, and be impacted by, executions of other business processes 100.
One way to assist the development of new or modified business processes 100 is to simulate the execution of the new or modified business process 100. However, traditional business process simulation environments are fairly simple and simulate business processes 100 based on user-defined parameters, such as assumed transaction arrival rates, expected subtask execution time, and expected outcomes of branch condition evaluations. While this can be useful for an approximate analysis, it is insufficient to get a complete understanding of the potential impact caused by the new (or modified) business process 100.
In particular, existing approaches to business process simulation have several drawbacks. First, they do not take into account the load on resources and services (possibly caused by executions of different business processes 100). The performance of resources and services are likely to drop as the number of business process executions increase. Second, they do not take into account the load on the BPMS and the limited system capacity to execute business processes 100. Third, simulation parameters are provided by the user, often based on very rough estimates. While parameters describing average execution times are important, the behavior of the BPMS and of resources may deviate considerably from these average values. For example, some services may be very effective on weekdays, but very slow on weekends. These deviations need to be taken into account in order to avoid business processes 100 that have a reasonable average quality but that may still be affected by frequent quality degradations.
Thus, one problem with conventional methods and systems for designing business processes 100 is that they fail to provide the capability to redesign a business process 100 in a cost efficient fashion. Another problem with such conventional methods and systems is the failure to take into account the load on business process resources and services, as well load on the BPMS and its limited capacity to execute business processes 100 and services. Another problem with conventional methods and systems is the inaccuracy of simulation parameters, which are based on rough guesses.